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EXECUTIVE SUMMARY 



LAYERED SYSTEM ARCHrTECTtmE mXH HEADERyDESCRIPTORS 

T.C Grand Alliance HD1^ Sys.. . ^ la^^^^ 
headers/descriptors to provide flexible op«^™8 

. SeYr«;;irni^'is»"ss^^^^-"^"''"'^°^''^'" 

in the 6 MHz simulcast channel . 
WhU. an of *e OA mrv system's lay«s ^'Z^m'^-^^'^^^'^y^ 



PICTURE LAYER 



The picture layer consUts of raw pixel data, "J.^.^g"'^ S^^H^JIumX any 
mtV system provides for muldple ff^S^^lS^'JJSilnd aSrion developers to make 
Sa HDTV receiver. This approach P'^^'SidfacB and interface artifacts, and 
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ExGrijtiv/^ Nummary 



i Spatial format x Y active pixels) 
ixou X /zu (.square pixeis) 


Temporai rate 
23.y76/24 Hz proeressivc scan 


29. y 7/30 Hz progressive scan 


iy20x 1080 (square pixels) 


59.y4/6Q Hz progressive scan 

23.y76/24 Hz progressive scan 


29.^)7/30 Hz proeressive scan 
39.94/60 Hz interlaced scan 



COMPRESSION LAYER 



The compression layer transforms the raw video and audio samolcs into a coded hir «rr^-,™ 
cssennaUy a set of computer instructions and data that arc execS by Se receh^^to mcSa^^^^^ 
pictures and sound. TTie compression layer of the Grand AlUance fflDTV^tem^^^^ 

• uses video compression syntax diat conforms to the ISO-NlPEG (Intemarional Standards 
C^anizanon - Movmg Picture Expcns Group) MPEG-2 videoXHomp^^^^^^^ 
standard, at a nonunai data rate of approximately 18.4 Mbps. compression oratt 

• uses Dolby AC-3 audio compression, at a nominal data rate of 384 kbps. 



TRANSPORT LAYER 



separately packeazes video, audio and auxiliary data and aJlows their mix to 
vary dynamically, providmg the flexibility needed to innovate new services a^dLwti^ if 
programming. TTie transport layer of the Grand Alliance HDTV systtm: 

* uses a packet format that is a subset of the MPEG-2 transpon protocoL 

' SaJylaTc^Si"''''"'" "^'^ ^^'"'^ ^^^^"^^^"'^^ surround-sound audio and 

* aS^nS,?'. ^r^**^^ ^" Of ^deo. audio and data services Aat can be provided to 
appropriately-featured receivers. It separately packages each type of data vidTo audio 

lS.;?n:'7,K".°^ transmission packets. Each packet has a plketm l^l&^^^c^tl 
Ac content of the data stream. This capability enables the creation of new services ranp?n^^ 
fram rn^y stereo channels of audio, to broadcast distribudon of compu«r sTfSSe^o^tSf 
transmission of very high resolurion srill images to computers. wiware, to tne 

* mcSl?n!fdrSn°/ '° b^<ly"!?icaIly allocated. This capabiHtv will allow rapid bunt- 
SSS SnTA° ' «"able broadcasters to send mdtiplc "sbSw^^ 
rri^;L^° data programmiiig to their audience. aU complemenring or enlLcingihc^bask 
program content. This capabUity can fundamentally change thf nature S feStisk,n 

?o^mSV^"^%-^^^ 

* Sacke1'^T.°ES^^.H "''"^^^^ f * ^^'^ '^^^^ ra^TV receiver will disregard any 
packet widi a HD header that it does not recognize or cannot process. This will euSnate 
ft^omj backward-compaabilicy" problems in the'instailed base of'^Sm. ™>^n/a S 
constraint from the introduction of new services. icuovos. removing a crucial 

Grand Alliance System Spec Uoo^ment 



BNSDOCID: <XP__2055175A_L> 



ansmission layer ^ 

Hzanalogchanncl. m «»cn ^V"'™ .j^xuna-cly 18.8 Mbps in *e 6 
. uses a treUis-coded 8-VSB modulanon techmdue to deuvn app 
MHz«n«malsimalcas.ohannd i„crcases pdl-in mge. 

:^:t:^u^:6^SB^»duUdo„«ch»^ue.od.Uv«™o.8.8Mbps^ 
MHz cable television channel 

^TV in many industries. 
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The Grand Alliance Transport System 
1. Introduction 

This document provides a descripdon of the funcnonaUty and fonnat of the Grand Alliance 
transpon system. While tutorial in nature, the document provides sufficient technical detail to 
serve as the opemdonal specification of the tnuispon layer. Issues related id terrestrial broadcast 
and cable delivery of the ATV service, in the context of ACATS discussions, are addressed in this 
documenL TTie auAors have attempted to make this a stand-alone document, though Ac reader 
would gam addidonal insight from associated ISO-MPEG documents on this and related topics. 

In developing the specification of the Grand Alliance transpon layer, we have drawn upon the 
collecuve expenence of the member companies in developing individual systems, as weU as die 
exceUent body of work created by the ISO-MPEG standards process. While any system design 
rcqmr« inteUigent tradeoffs to be made, selection of a format based on fixed-length packets has 
maintained a number of simultaneous goals. 

1.1. Program vs. Transport stream multiplexing 

In general there are two approaches for multiplexing elementary bit streams from multiple 
apphcaaons on to a single channeL One approach is based on die use of fixed length packets and 
the odier on variable length packedzadon. Both approaches have been used in die MPEG-^ 
suuidard. As illustrated in Hg. l.l. the video and audio elementary streams in both cases go 
duough an initial stage of PES packetization (discussed in greaterdepth later), which results in 
varuble lengdi PES packets. TTie process of generating die mmsmined bit streams for die two 
approaches is shown to involve a difference in processing only at the final multiplexing stage 
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Fig 1.1. Comparison of system level muldplexing approaches. 



Fig. 1.2 gives examples of bit streams for the both program and cranspon scream approaches, in 
order to clarify their difference. As shown in Rg. 1,2b, in a program stream approach, PES 
packets from various elementary bit streams are-mulaplexed by cransmictxng the bits for the 
CPmgictC PES packets in sequence, thus resulting in a sequence of variable lenyth packets on the 
channel. (As shown in the diagram, each PES packet is preceded by a PES packet header.) In 
contrast to this approach, in the rransporr sms^m approach selected for the GA system, the PES 
packets (including the PES headers) are transmitted as the payload of fixed length iranspon packets. 
Each transpon packet is preceded by a tianspon header which includes inforaiadon for bit stream 
idendficarion. As illustrated in Fig. 1,2a, each PES packet for a particular elementary bit stream 
occupies a variable number of cranspon packets, and data from various elementary bit streams are 
generally intericaved with each other at the transpon packet layer, with idendficarion of each 
elementary bit stream being facilitated by data in the cranspon headers. New PES packets always 
Stan a new transpon packet in the GA system, and snifFmg bytes arc used to fill packets with 
partial PES data. 



Grand Alliance HDTV System Specification 

Page 4 . 



Draft Docoment 



I - PCS header 



I - transpon header 




a- Transport stream 




b. Program scream 



Fig. 1.2. niustration of bit streams for the two packi 
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L2. Advantages of the flxed length packetization approach 
The fixed length packedzadon approach offers a great deal of flexibility and sotne addidonal 
advantages when aaempting to muldplex data related to several applications on a single bit streaxtL 
These axe described in sotne detail in this secdon. 



Dimamic Capacity Allocation: 

While digital systems arc generally described as flexible, the use of fixed length packets offers 
cotnpletc flexibility to allocate channel capacity among video, audio and auxiliary data services. 
The use of a packet id (or PED) in the packet header as a means of bit stream idenrificadon makes it 
possible to have a mix of video, audio and auxiliary data which is flexible and which need not be 
specified in advance. The cndre channel capacity can be reallocated in bursts for data delivery. 
This capability could be used to distribute dccrypdon keys to a large audience of receivers during 
the seconds preceding a popular pay-per-view program, or download program-related, computer 
software to a "sman receiver." 

Scalability: 

The transport format is scalable in the sense that availability of a larger bandwidth may also be 
exploited by adding more elementary bit streams at the input of the multiplexer, or even 
multiplexing these elementary bit soxams at the second multiplexing stage with the original bit 
sueam. This is a critical feature for network distribution, and also senses interoperabUity with a 
cable plant's capability to deliver a higher data rate within a 6 MHz channel. 

Extensibility: 

Because there will be possibilities for future services that we caimot antic^)aie today, it is extremely 
important that the transpon architecmre provide open-ended extensibility of ser/ices. New 
elementary bit streams could be handled at the transport layer witiiout hardware modifications, by 
assigning new packet IDs at the transmincr and filtering on these new PiDs in the bit stream at the 
receiver. Backward compatibility is assured when new bit streams are introduced into the oanspon 
system since existing decoders will automadcaUy ignore new PEDs, This capability could possibly 
be used to compatibly introduce "1000-Une progressive fornuts" or "3D- HDTV" by sending 
augmentation data along with the normal ATV data. 

Robustness: 

Another fundamental advantage of the fixed length packedzadon approach is shac liK^ fixed length 
packet can form the basis for handling errors that occur during transmissioa. Brorcarrection and 
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dctccaon processing (which prrccdcs packet demultiplexing in die receiver subsystem) may be 
synchronized ro the packet stnicturc so that one deals at the decoder wid, units of packets when 
handling dau loss due to nansmission impairments. Essentially, after detecting errors during 
cnmsmission. one ttcovers the data bit stream from the first good packet Recovcty of 
synchronization within each application is also aided by die transport packet header infomiation 
Without this approach, itcovery of synchronization in the bit streams would have been completely 
dependent on the properties of each elementary bit stream. 

Cost Effective Receiver Implementations: 

A fixed-length packet based transport system enables simple decoder bit satam demultiplex 
orrhi^ctures suitable for high speed implementations. TTie decoder does not need deodled 

elen^ntary bit streams at d« demultiplexer. AU die receiver ne^ 

packet, which IS transmitted in each packet header at fixed and known locations in die bit stream 
TTie only unportant timing infomiation is for bit level and packet level synchronization. 

MPEG.2 Compatibility: 

me GA transport system is based on die MPEG-2 system specification. While die MPEG-2 
syst«i layer has been designed to support many different transmission and storage scenarios care 
has been taken by MPEG, as weU as die Grand AlUance. to limit die burden of pLt^ol 
inefHcrencies caused by this jenenlity in definidon. 

An «ldidon>l advanag. of MPEG.2 comp^ibmv « inn»p«bUiv «i* «h«r MPEG.2 
app-jcaoons. 11,. MPEO-2 fon™, «, b, u«i for a nun,6c of «h.r appBcadons 

stoag. of co»p„«od bi. ^_ZtV «.cv;sion 

While GA oanspon foma, confonm »> .he MPEG-2 sysBnB fomm. i. *iu no. exercise aU d,e 
^bU.„es defied in ^ MPEG.2 ™,spoa Wo., a GA Sys.en, decode, need noTC 
l^EG.2 sysKms compUan^ in cha, i, will n« be able » decode aririmin- MPEG.2 svnem hi, 
However, all MPEG.2 decoder should be able „ decode! G^.^ '^ZZ 
-^^s.«nl.vel. Dccun«n»de<iningd„a.«n.„«bichU.MPEO«p^!: 
.o °A been s„bn««d „ *e MPEG cca»ine. aThave cT^flMed 

.od,ee«r,entwortangdr,f,ofd,es«ndani. (See A^chmen, I.) MPEG-2 s«kW frn;;;^« 
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supponed in the GA spccificarion were constrained^ if they were deemed to not be applicable to 
broadcast/cable delivery of ATV. 

In the development of the GA transport specificadon, the intent has never been to litnit the design 
by the scope of the MPEG-2 systems defmidon. If the MPEG*2 standard is unable to efficiendy 
meet die requirements of the GA system, a deviadon from MPEG would be in order. The 
Advisory Commiaee would be notified should there be a future deviadon firom MPEG, with 
jusdficadon for the change/ 

1.3. Overview of the transport subsystem 

Fig. 1.3. illustrates the organizadon of a GA transmitter-receiver pair and the locadon of the 
transpon subsystem in the overall system. The transpon resides between the applicadon (e.g. 
audio or video) encoding/decoding function and the transmission subsystems. At its lowest layer, 
the encoder transpon subsystem is responsible for formatting the enccxied bits and muldplexing the 
different components of the program for transmission. At the receiver, it is responsible for 
recovering the bit streams for the individual applicadon decoders and for the corresponding error 
signaling. (At a higher layer, muldplexing and demultiplexing of multiple programs widiin a single 
bit stream can be achieved with an additional system level multiplexing or demultiplexing stage 
before/after the modem in the transmitter/receiver.) The transpon subsystem also incorporates 
other higher level functionality related to identificadon of applications and, as illustrated, 
synchronization of the receiver. This document will describe these functions in greater detail. 



The constraint takes the form of a limitation of functionality. In this instance, 
cenain flags will be permanently configured, and some Fields will not appear in the 
Grand Alliance bitstream. This allows a simpler decoder, as it will not be necessary to 
handle elements not used for the Grand Alliance application. Often constraints are 
grouped as a "profile" when acknowledged by the MPEG standards body. 
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Hg. 1.3. Sample organization of functionality in a transmincr-rcceivcr pair for a single GA 
program* 



As described carUer. the data transport mechanism in the GA system is based on the use of fixed 
length packets that ait idcndficd by headers. Each header identifies a pamcular appUcarion bit 
stream (also called an elemenxary bit stream) which forais the payload of the packets. Applications 
supponed include video, audio, data, program and system control infonnarion. etc.. As indicated 
earlier, the elementary bit streams for video and audio arc themselves be wrapped in a variable 
length packet smicnire caUcd the packet elementary stream (PES) before nanspon processing. The 
PES layer provides functionality for identification, and synchronizarion of decoding and 
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prcscniadon of ihe individual appUcadon. The format and funcdonalicy of a PES packec is described 
in a later section.^ 

Moving one level up in the descripdon of the general organizadon of the GA bit streams, 
eiemencary bit streams sharing a common dme base are muldplexed, along with a control data 
stream, into programs. These p ro gra ms and an overall system conorol data stream are then 
asynchronously muidplexed to form a muldpiexed system. The organizadon is described in detail 
in a later secdort Note that p ro gr a ms in the GA system are analogous to today's NTSC broadcast 
channels. 

At this level the GA transport is also quite flexible in two aspects: 

1. It permits you to de5ne programs as any combinadon of elementary bit streams, for example the 
same elementary bit stream could be present in more dian one program (e.g., two bit streams widi 
the same audio), a program could be formed by combining a basic elementary bit stream and a 
supplementary elementary bit stream (Le., bit streams for scalable decoders), programs could be 
tailored for specific needs (e,g.. regional selecdon of language for broadcast of secondary audio), 
etc.... 

2. Flexibility at the systems layer allows different programs to be multiplexed into the system as 
desired, and allows the system to be reconfigured easily when required. The procedure for 
exoracrion of programs from within a system is also simple and well defined. 

The GA format provides other features that are useful for both normal decoder operation and for 
the special features required in broadcast and cable applications. These include 

1 . Decoder synchronization 

2 . Conditional access 

3. Local program insertion, etc..,. 

The elements of chcsc features that are relevant to the standard definition process will be discussed 
in detail. 

The GA bit stream definition direcdy addresses issues related the storage and playback of 
programs. Although, this is not direcdy related to the ATV transmission problem, it is a 
fundamental requirement for creating programs in advance, storing them and pfaying them back at 
die desired time. The programs are stored in die same format in which they arc transmitted, i.e.. as 

^Note that the PES layer is not required for all applications. Its ue is mandated for 
both die video and audio in die GA system. 
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transport bit streams. The GA bit snrcam fonnat also has the hooks in it to support the design of 
consumer digital products based on recording and playback of diese bit streams, including the use 
of the "crick modes" that one is familiar with for current analog VCRs. It should be noted that the 
issues related to storage and play back of digitaUy compressed video bit streams are quite different 
firom those (hat need to be considered for analog systems such as NTSC 

1.4. General bit stream Interoperability issues 

The question has been raised frequendy about die bit stream level interoperability of the GA 
systentL There are two sides to this issue. One is whether the GA transport bit stream can be 
carried on odicr communication systems, and die other is die ability of die GA system to cany bit 
streams generated from other communicadon systems. 

The fii5t aspect of transmitting GA bit streams in different communication systems has been 
addressed to some extent (e.g.. for ATM interoperabiUty) in die design of die protocol, and is 
described in more detail in later sections. In shon, there is nodiing diat prevents die transmission 
of a GA bit stream as die payload on a different transmission system. It may be simpler to achieve 
diis functionality in certain systems, e.g., CATV. DBS, ATM. etc, dian in odicrs. e.g.. computer 
networks based on pn>tocols such as FDDI. EEE 802.6, etc.. Since ATM is expected to fonn die 
basis of future broadband communications, it is beUeved diat die issue of bit stream interoperability 
has been addressed for one of die more important transmission scenarios of die future. This is 
discussed in more detail in Chapter 9. 

The odier aspect is of toinsmitring odier, non-GA. bit streams widiin die GA system. This makes 
more sense for bit streams linked to TV broadcast applications. e.g., CATV, DBS, etc.., but is 
also possible for odier "private" bit streams. TTiis function is achieved by transmitting these odier 
bit streams as die payload of identifiable transport packets. The only requirement is to have die 
general nature of diese bit streams recognized widiin die GA system context Note diat diere is 
also a certain minimum system level processing defined by die GA diat needs to be implemented to 
extract all (even private) bit streams. The details are made clearer in die sections that follow. It is 
also important to remember diat die GA system is essentially a broadcast system and hence any 
private transmissions diat may be based on a two way communications protocol wiU not be direcdy 
supported, unless diis functionality is provided external to die GA system definition. 
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2. The packetization approach and Tunctionality 

The GA oanspoit bit stream consists of fixed length packets with a fixed and a variable component 
to Che header field as iilustrated in Fig. 2.1. 



\^ 188 bytes 

I Variable 

I-*- 4 bytes ^.jcngdi 
lAdaptaaon 

; link- header ; ^^^^^ 



(not to scale) 



Fig*2.L GA Transport packet format 

Each packet consists of 1 88 bytes. The choice of this packet size is motivated by a few factors. 
The packets need to be large enough so that the overhead due to the cranspon headers do not 
become a significant ponion of the total data carried. They should not be too large that the 
probability of packet error becomes significant under standard operadng condidons (due to 
ineffideni error coxrecdon). It is also desirable to have packet lengths in rune with the block sizes 
of typical, block oriented, error correcdon approaches, so that packets may be synchronized to 
error correction blocks, and the physical layer of the system can aid the packet level 
synchronizadon process in the decoder. Another modve for the pardcular packet length seiecuon is 
interoperability with the ATM format. The general philosophy is to transmit a single GA transpon 
packet in four ATM cells. There are, in general, several approaches to achieve this fiincdonality. 
Chapter 9 includes a discussion of some example approaches. If this interface is to be 
Standardized, the issue will be setded outside the scope of the GA/ACATS process. 

The contents of each packet and the nature of this data arc identified by the packet headers. The 
packet header structure is layered and may be described as a combinarion of a fixed length "link" 
layer and a variable length adaptation layer. Each layer serves a different functionality similar to 
the link and transpon layer functions in the OSI layers of a communications syszeoL This link and 
adaptation level functionality is direcdy used for the terrestrial link on which ±c GA bit stream is 
oansmittcd However these headcn could also be completely ignored in a (fififcrtnt system (e.g. 
ATM), in which the GA bit stream may just remain the payload to be carried, la this environment. 
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(he GA bit stream headers would serve more as an identifier for the contents of a data stream rather 
than as a means for implementing a protocol layer in the overall transmission system. 

2.1. The -link" layer 

The link layer is implemented using a four byte header field. The format of the header field is 
described in greater detail in a later secrion. Some of die important functions diat are enabled by 
the header eletnents arc described here. 



2.1.1. Packet synchronization 

Packet synchionizarion is enabled by die sync.byte. which is die fint byte in a packet The sync.byte 
has die same fixed, pre-assigned, value for all GA bit streams. In some impiementarions of 
decoders die packet synchronizadon function is done at die physical layer of die oommunicarion 
link (which precedes die packet demultiplexing stage), in which case this sync.byte field may be 
used for verification of packet synchronization function. In odier decoder implementations diis 
byte naay be used as die primary source of infonnarion for estabUshing packet synchronization. 
The standard does not specify die details of die approach to be used to implement diis function in a 
decoder but only provides die hooks in die bit stream to facilitate die function, 

2.1.2. Packet Identification 

As discussed earlier, an important element in die link header is a 1 3 bit field called die PID or 
Packet ED. This provides the mechanism for multiplexing and demultiplexing bit streams, by 
enabling identification of packets belonging to a particular elementary or control bit stream. Since 
die location of die PID field in die header is always fixed, extraction of die packets corresponding to 
a particular elementary bit stream is very simply achieved once packet synchronizadon is 
established by filtering packets based on PiDs. TTie fixed packet lengdi makes for simple filter and 
demultiplexing implementations suitable for high speed transmission systems. 

2.1.3. Error handling 

Enor detection is enabled at die packet layer in die decoder dirough die use of die continuity.counter 
field. At die transmitter end. die value in diis field cycles fiom 0 dirough 15 for all packets widi 
die same PID diat cany a data payload (as wiU be seen later, die GA transpon allows you to define 
packets diat have no data payload). At die receiver end. under normal conditions, die reception of 
packets in a PID stream widi a discontinuity in die coniiniiity.couiiBr value indicates diat data has 
been lost in transmission. The transport processor ai die decoder dien signals die decoder for die 
particular elementary stream about die loss of data. This signaling approach is not included in die 
standard. 
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Because certain infonnadon (such is headers, dnie scamps* and program maps) is very imponanc 
to the smooth and condnuous operadon of a system, the GA cranspon system has a means of 
increasing the robusmess of this informadon to channel errors by providing a txiechanism for the 
encoder to duplicate packets. Those packets chat contain important informadon will be duplicated 
at the encoder. At the decoder, the duplicate packets are either used if che original packet was in 
error or are dropped Semandcs for idendfying duplicate packets are described in the descripdon 
of the condnuicy.cQunter. 

Conditional Access 

The cransport format allows for scrambling of data in the packets. Each elementary bit stream in 
the system can be scrambled independendy. The GA standard specifies the descrambling approach 
to be used but does not specify the descrambling key and how it is obtained at the decoder. The 
key must be delivered to die decoder widiin a dme interval of its usefulness. There is "private** 
data edacity at several locadons widiin che GA transpon stream where this data might be carried. 
Two likely locadons would be 1) as a separate private stream with it's own PID, or 2) a private 
field within an adaptadon header carried by the PUi of die signal being scrambled. The security of 
che condidonal access system is ensured by enciypdng the descrambling key when sending it to che 
receiver, and by updating the key frequently. As mendoned before, die key encrypdon, 
oansmission, and decrypdon approaches are not a pan of the standard and could differ in difxerenc 
versions of che ATV delivery system. There is no system imposed limit on che number of keys 
that can be used and the rate at which chese may be changed. The only requirement in a receiver to 
meet die standard is to have an interface from the decryption hardware (e.g., a Sman-card) to the 
decoder that meets die standardized interface spec. The decrypdon approach and technology is 
itself not a pan of the standard. For the purposes of testing, to demonstrate feasibility, only che 
descrambling fiincdon will be tested and die encrypdon keys will probably be made direcdy 
available at che decoder. Note diat die generalized systems layer definirion includes a mechanism 
for cransmicdng key informadon, including the process of idendfying bit streams carrying key 
informadon and die definirion of die tables diat enable this function. 

Informadon in che link header of a transport packet describes if die payload in the packet is 
scrambled and if so, flags die key to be used for descrambling. The header informadon in a packet 
is always transmitted in die clear, i.e., unscrambled The amount of data to be scrambled in a 
packet is variable depending on die lengdi of die adaptadon header. It should be noted dia^some 
padding of die adaptadon field might be necessary for ctnain block mode algorithms. Condidonal 
access is discussed in greater detail in a later section. 
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Sote that the general MPEG<2 transport definition provides the mechanism to scramble at two 
levels, within the PES packet structure and at the transport layer. Scrambling at the PES packet 
layer is ptitxarily useful in the program stream (which is not supponed in the GA system), where 
chere is no protocol layer similar to the tianspon to enable this function. In the GA system 
scrambling will be implemented only at the transpon layer. 

2.2. The Adaptation layer 

The adaptation header in the GA packet is a variable length field. Its presence is flagged in the link 
levd section of the header. The functionality of these headers is basically related to the decoding of 
the elementary bit stream that is extracted using the link level functions. Some of the functions of 
this layer that are important to the functioning of the GA system arc described here. 

2.2.1. Synchronization and timing 

Synchronization of the decoding and presentation process for the applications running at a receiver 
is a particularly important aspect of real time digital data delivery systems such as the GA system. 
Since received data is expected to be processed at a paracular rate (to match the rate at which it is 
generated and transmitted), loss of synchronization leads to either buffer overflow or underflow at 
the decoder, and as a consequence, loss of prcscntation/display synchronization. The problems in 
dealing ivith this issue for a digital compressed bit stream are different ftom those for analog 
iNTSC In NTSC, information is transmitted for the pictures in a synchronous manner, so that one 
can derive a clock direcdy from the picture synch. In a digital compressed system the amount of 
data generated for each picnirc is variable (based on tfie picmre coding approach and complexity), 
and timing cannot be derived direcdy firom the Stan of picture data. Indeed, there is really no 
naniral concept of synch pulses (that one is familiar widi in NTSQ in a digital bit stream. 

The solution to this issue in the GA system is to transmit timing information in die adaptation 
headers of selected packets, to serve as a reference for timing comparison at the decoder. This is 
done by transmitting a sample of a 27 MHz clock in tiie program.clock.refeience (JCR) field, which 
indicates the expected time at the completion of the reading of tiuit field from the bit stream at the 
transpon decoder. The phase of the k)cal clock running at the decoder is compared to the PGR 
value in the bit stream at the instant at which it is obtained, to determine whetiier the decoding 
process is synchronized. In general, the PCR from the bit stream does not direcdy change die 
phase of the local clock but only serves as an input to adjust the clock rate. Exceptions are during 
channel change and insertion of local programming. As mentioned earlier, the nominal clock rate 
in tfjc G A decoder system is 27 MHz. A point to note here is diat the standard only specifics the 
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means of nnsmiuing synchronization information lo a receiver but does not specify the 
iniplementation of the synch recovery process. Note also that the audio and video sample clocks in 
the decoder system arc locked to the system clock derived from the PCR values. TTiis simpfifies the 
receiver implementation in terms of the number of local osdllaiors required to drive the complete 
decoding process, and has other advanages such as rapid synch acquisition. 

Details of the format for the PCR are given in a later secdon. Note that in this implementation the 
encoder and decoder system clocks are set completely independent of the modem dock. This 
makes for a clean separation of functionality when implementing the two subsystems, and leads to 
simpler interfaces. This also makes it simpler to interface GA transmitters and receivers at the 
transport interface to modems which may be used for transmission on other media such as CATV. 
DBS. computer networks, etc.. 

2.2.2. Random entry into the compressed bit stream 

Random entry into die application bit streams such as video and audio is necessary to suppon 
functions such as program tuning and program switching. Random entry into an application is 
possible only if die coding for the elementary bit stream for dte application supports diis 
functionality dirccdy. For example, a GA video bit stream supports random entry through the 
concept of Intra (or I-) frames that arc coded widiout any prediction, and which can therefore be 
decoded widiout any prior information. The beginning of the video sequence header information 
preceding data for an I-frame could serve as a random entry point into a video elementary bit 
stream. In general, random entry points should also coincide widi die stan of PES packets where 
diey are used, e.g.. for video and audio. The support for random entry at die transpon layer 
comes from a flag in the adaptation header of the packet that indicates whedier the packet contains a 
random access point for die elemeniaiy bit stream. In addition, die data payload of packets that arc 
random access points also stan widi die data that forms the random access points into the 
elementary bit stream itself. This approach allows the discarding of packets dirccdy at die transport 
Uycr when switching channels and searching for a resynchroniration point in die transpon bit 
stream, and also simplifies die search for die random access point in die elementary bit stream once 
transpon level resynchronizarion is achieved. 

A general objective is to have random entry points into the programs as ftcqueody as possible, to 
enable rapid chaxmcl switching 

9 
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2.2.3. Local program insertion 

This functionality is important for inserting local prognumning, e.g., commercials, into a bit 
stream at a broadcast headend. In general, there are only certain fixed points in the elementary bit 
screams at which program insertion is allowed. The local insertion point has to be a random entry 
point but not all random entry points are suitable for program insertion. For example, for GA 
video, in addirion to being a random entry point, the VBV.dclay (video buffer verifier delay) needs 
CO be at a certain system defined level to permit local program insertion.^ This is a requirement to 
control the memory needed at the decoder for buffering data and to prevent buffer overflow or 
underflow. Local program insertion also always takes place at the transpon packet layer, i.e., the 
data stream splice points are packet aligned. Implementation of the program insertion process by 
the broadcaster is aided by the use of a splice.councdown field in the adaptation header that indicates 
ahead of time the number of packets to countdown until the packet after which splicing and local 
program insertion is possible. The insertion of local programming usually results in a 
discontinuity in the values of the PGR received at the decoder. Since this change in POl is 
completely unexpected (change in PGR values arc usually only expected during program change), 
the decoder clock could be thrown completely out of synchronization. To prevent this from 
happening, information is transmitted in the adaptation header of the first packet after the splicing 
point to notify the decoder of the change of PGR values (so that it can change the clock phase 
dirccdy instead of attempting to modify the clock rate). In addition there are constraints on 1) the 
length of the bit stream that is to be spliced in, to assure that the buffer occupancies at the decoder 
both with and without the splice would be consistent, and 2) the initial VBV value assumed when 
encoding the bit stream to be spliced in, in order to prevent decoder buffer underflow or overflow. 

The details of the syntax elements that support splicing and local program insertion are described in 
die chapter on the transpon format. More specifics of the particular implementation for the GA 
system will be described in a separate section. 

In addition to the functions described above, the adaptation header includes capabilities for 
extension of the header, for supporting new functionality, and also for defirung data that is private 
and whose format and meaning arc not defined in the public domain. These elements may be 
useful in extending the GA o^sport beyond the current range of expectations for usage. 



The VBV_delay information is computed and transmitted as a part of the header data 
for a picture in the compressed video bit stream. It defines how full the decoder 
video buffer should be just before the bits for the current picture are extracted from 
the buffer, if the decoder and encoder processes are synchronized. 
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3. Higher Level Multiplexing functionality 

As described earlier, the overall multiplexing approach can be described as a combination of 
muiriplexing at two different layers. In the first layer one forms program transport streams by 
multiplexing one or more elementary bit streams at the transpon layer, and in the second layer the 
program transpon streams are combined (using asynchronous packet multiplexing) to form the 
overall system. The functional layer in the system that contains both this program and system level 
information that is going to be described is called the PSI or Program Specific Information. 

3.1. Single Program Transport Multiplex 

A GA program transpon bit sneam* is formed by multiplexing individual transport packetized 
elementary bit streams (with or without PES packetizarion) sharing a common time-base, and a 
control bit stream that describes the program. Each elementary bit stream, and the control bit 
stream (also called the elementary stream map in Fig. 3. 1), are identified by their unique PIDs in the 
link header field. The organization of this multiplex function is illustrated in Fig. 3.1. The control 
bit stream contains the program.map.table that describes the elementary stream map. The 
program.map.table includes infoimation about the PEDs of the transport streams that make up the 
program, the identification of the applications that are being transmitted on these bit streams, the 
relationship between these bit streams, etc.. The details of the program.map.table syntax and the 
funcrionalit>' of each syntax element are given in a later section. The identification of a bit stream 
carrying a piogram_map_table is done at the system layers to be described next. 

The transport syntax allows a program to be comprised of a large number of elementary bit 
streams, with no restriction on the types of applications required within a program. A program 
ffansport stream does not need to contain compressed video or audio bit streams, or, for example, 
it could contain multiple audio bit streams for a given video bit stream. The data appUcarions that 
can be carried are flexible, the only constraint being that there should be an appropriate smam.type 
ID assignment for recognition of the application corresponding to the bit stream in a GA decoder. 
The list of appUcation t>'pes that will be a supported in the initial GA system are given in the section 
on services supported by the GA system. Note that the initial selection of appUcations does not 
limit the future, andeed. it is quite impossible for one to anticipate all possible fuwre 
applications!) 



The icraimology can be confusing. A program is analogous to a channel in NTSC. 
A program stream refers to a particular biisiream format, described in tbe 
introduction, that is not being used in the GA system. A pra-raB transport 
stream is a icnn used to describe a transport bitstream that has beea ssneraied for a 
program. 
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Note that many of the link level functions are carried out independently, without program level 
coordination, for the different elementary bit streams that make up a program. This includes 
functions such as PID manipulation, bit stream ffltering, scrambling and descrambling, definition 
of random entry packets, etc.. The coordination between die elements of a program is primarily 
controlled at die presentation (display) stage based on the use of the common time base. This 
common time base is set up by die fact diat aU elementary bit streams in a program derive riming 
information from a single clock, die information for which is transmitted via die PCR on one of die 
elementary bit streams diat constitute die program. The data for timing of presentation is present in 
the elementary bit streams for individual applications. 



Elementary stream 1 (Video?) 
Elementary stream 2 (Audiol?) 

Elementary stream 3 (Audio2?) 



PBDl 



PID2 ^ 



PID3 



Elementary Stream n-1 (Datai) ' PID(n-l^ 



Elementary Scream n (Data j) 
Elementary stream map 
(prograni_map_tabl e) 



PIDn 



PID(n+^ 




MUXcd 
program 
transport 
bitstream 



Fig. 3. 1. Illustration of die multiplex function to form a program transport stream. 



Aldiough diere is no restriction on die PID values diat can be assigned widiin a program transport 
multiplex, in Ught of die fact diat PiDs need to be unique at a system level, a standardized PID 
assignment approach should be considered for die GA system. A suggestion is to use the LSB bits 
in die PiDs to identify die stream type. 

3.2. System Multiplex 

The system multiplex is die process of multiplexing different program transpon streams. In 
addition to die transport bit streams (widi die corresponding PiDs) that define die individual 
programs, a system level control bit stream widi PID = 0 is defined. This bit stream carries die 
prognunj»ssodaiion_tablc diat maps program identities to dieir program transport streams. The 
program identity is represented by a number in die program.assodadon^ablc. A program conesponds 
to what is traditionally called a channel, e.g.. HBQTM. ESPNTM, eu;.. The map indicates die PID 
of die bit stream containing die prognun_map.tabIe for a program. TTius, die process of identifying a 
program and its contents takes place in two suges: first one uses die prognm^associadon.table in die 
PID = 0 bit stream to identify die PID of die bit stream carrying the pogramjnap.ubte for die 
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program, in the next stage one obtains the PIDs of the elementary bit streams that make up the 
program from the appropriate program_map_tablc. Once this step is completed the filters at a 
demultiplexer can be set to receive the tianspon bit streams that correspond to the program of 
interest. 



The system layer of multiplexing is Ulustrated in Rg. 32. Note that during the process of system 
level multiplexing, there is the possibility of PIDs on different program streams being identical at 
the inpuL This poses a problem since PIDs for different bit screams need to be unique. A solution 
to this problem lies at the multiplexing stage, where some of the PEDs could be modified just 
before the multiplex operation. The changes have to be recorded in both the program.associaiion.table 
and the piograni_map_table. Hardware implementation of the PID reassignment function in real time 
is helped by the fact that tiiis process is synchronous at the packet clock rate. The other approach, 
of course, is to make sure up front that the PIDs being used in the programs that make up the 
system are unique. This is not always possible with stored bit streams. 



Program transport stream 1 
Program transport stream 2 
Program transpon stream 3 



Program tianspon stream 
Program transport stream 5 

Program stream map 




System level multiplex 



(program.associcatlon.table) 
Fig. 3.2. Illustration of the multiplex function to forni the system level bit stream. 

Note that the architecmrc of the GA bit scream is scalable. Multiple system level bit streams can be 
multiplexed together on a higher bandwidth channel by extracting the prognun.associarion.tables from 
each system multiplexed bit stream and reconstructing a new piD = 0 bit stream. Note again that 
PIDs may have to be reassigned in this case. 



Note also that in aU descriptions of the higher level multiplexing functionaKty no mention is made 
of the functioning of the multiplexer and multiplexing poUcy that should be used. This function is 
not a pan of the standard and is up to individual designers. Because its basic function is one of 
filtering, the transport demultiplexer will function on any GA bit stream regardless of the 
multiplexing algorithm used. 
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Fig 3.3 illustrates the entire process of extracting elementary bit streams for a program at a 
receiver. It also serves as one possible implementation approach (although not the most efficient! 
In practice the same demultiplexer hardware could be used to extract both the 
program.associaticn.tablc and the program_map_iable control bitstreams.). This also represents the 
minimum functionality required at the transport layer to extract any application bit stream (including 
those that niay be private). 



System ^ 
bit stream 




Ofxain programjnap.PID 
(PIO of bit stream containing 
the prograrajnap.table) 



Obtain PlOs 
for elementary 
bitstreams 



I 



Program 
Identity 



■12 
>v a. 



Dump other 
transport 
packets 



Fig 3.3. niuscration of transpon demultiplexing process for a program* 

Note that once the packets are obtained for each elementary bit stream in the program, further 
processing stages of obtaining the random entry points for each component bit stream, decoder 
system clock synchronization, presentadon (or decoding) synchronization, etc., need to take place 
before the receiver decoding process reaches normal operating conditions for receiving a program. 

It is important to clarify here that the layered approach to defining the multiplexing function does 
not necessarily imply tiiat program and system multiplexing should always be implemented in 
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separate stages. A hardware implementation that includes both the program and system level 
multiplexing within a single multiplexer stage is allowed, as long as the multiplexed output bit 
stream has the correct properties as defined in this documenL 
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4. Features and Services Supported by the GA ATV System 

As wc have demonstrated, the GA Transpon architecture has been designed to be maximally 
flexible and is capable of supporting a vast number of services through its system multiplex. The 
transport, however, is not the only means by which infomiarion can be delivered in the ATV 
system. The GA video syntax also provides means for delivery of predefined information. 

Although this is a global issue for the GA ATV system, it is appropriate to review the services 
supported in the context of the transport specification, since this sub-system has ultimate 
responsibility for the multiplexing of supported services. In this chapter, we will review a number 
of functions identified by ATSC document T3/1 86 and the SMPTE headers/descriptors group and 
describe how they arc carried within the ATV system. In some cases, these functions are a matter 
to be communicated between the smdio that sources the program and the fmal encoder that 
transmits the bit stream. While the fmal transmitted bit stream does not necessarily need to carry 
this information to the receiver, it is important to sec the capabilities of the ATV system to carry 
this information in a network distribution capacity. 

4.1. Features Supported within the Grand Alliance Video Syntax 
Pan & Scan: 

Pan & scan information is supported within the GA video syntax. This information is transmitted 
as an extension within the picture layer syntax. The pan scan extension allows decoders to 
define a rectangular region which may be panned around the entire coded image. This facility 
could be used to identify a 4:3 aspect ratio window within a 16:9 coded image. 

Field/Frame Rate and Film PulNdown: 

The GA video syntax provides means for transmitting the frame rate of the coded bit stream. This 
allows the encoder to maximize coding efficiency by not transmitting redundant fields, and signals 
the decoder the proper order for displaying the decoded pictures. The GA syntax suppons frame 
rates of 23.976, 24, 29.97, 30, 59.94 and 60 Hz as well as an extension for future capabilities. 
The frame rate syntax is found within the video sequence layer. 

Picture Structure Information: 

This information details the sampling soructure used in the coded image, including samples per 
line, lines per frame, and scanning format (interlace or progressive). This information is supported 
by the video syntax and is found within the sequence layer. 
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Picture Aspect ratio: 

The video syntax provides a field for sample aspect rano within the sequence layer. This 
informarion combined with the picture structure fields, allows the picture aspect ratio to be 
determined. 

Color field Identification: 

This informadon is supported by the GA video syntax and helps the decoder re-encode the image 
to an NTSC compadble output with reduced NTSC artifacts. 

Colorimetry 

Information on the colorimetry characterisrics of the video to be encoded are supponed by syntax 
in the video sequence layer This includes descriprion of the color primaries, cransfer 
characteristics and the color matrix coefficients. 

4.2. Features Supported as Multiplexed Services within the Grand Alliance 
Transport System 

As mentioned earlier, the GA transpon scheme provides great flexibility for multiplexing a variety 
of services in addition to video and audio elementary streams. Several possible services that could 
be supponed under this transpon definition are summarized below. 

.Audio Compression Types and Language Identification: 

The transpon layer syntax defines a program map which peraiiis identification of individual audio 
services by their compression algorithm as well as signaling the presence of a secondary language 
channel that can be selected by the viewer. 

Program Information 

This sen/ice could be provided to the decoder as an ancillary data service with its own PID, This 
could take the form of a TV guide that is personalized by the sernce provider. The information 
would require only a low refresh rate that would not consume a significant amount of the charmel 
bandwidch. 
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Other Program-related Information 

There is a large body of program-related information that could be identified for use at the decoder 
MPEG-2 systems syntax, on which the GA system is based, currendy supports copyright 
notificadon* but has not defined a separate capability for program classification data. This and 
other program-related information could be addressed as private data. 

4.3. Support of Closed Captioning 

The Grand Alliance has been participating in dialogue with die EIA committee on ATV Qosed 
Caption Standards to ensure proper support of this important feature. The standards group 
reviewed a number of important requirements for carriage of the closed caption service in a 
digitally compressed ATV system. In response to those stated needs, die Grand Alliance has 
indicated diat closed captioning would be carried as user data within the video picture layer. 

Support of closed caption in this manner, allows a fixed amount of channel capacity to be dedicated 
to the service, while maintaining absolute synchronization with each ATV frame. Carriage of this 
data as a separate service would require a separate synchronization mechanism as exists within the 
audio decoder. This synchronization was an essential requirement stated by the standards group. 
Additionally, this mechanism allows for relatively easy editing of the closed caption data 
downscreanx It is expected diat die closed caption data will require a dedicated allocation of 9600 
bits per second. 

Our work with this standards body will continue as we progress to final specifications, and our 
w(wk will be updated to the Advisory Conunittee. 

4.4. Features not Anticipated to be Transmitted by the Grand Alliance System to 
the Consumer Receiver 

Telecine Source Identification: 

Source identification information that could inform the encoder whether die video was originally 
film or video could assist the detection of redundant fields and diereby improve coding efficiency. 
There is no syntax provided in the video bit stream to carry this external information, however it 
could be multiplexed in at the systems level as an ancillary data service. 

Image Processing History: 

It is projected diat future encoders could take advantage of knowledge of any algoridims diat have 
been applied to die image sequence. This is knowledge tfiat would need to be passed from die 
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studio to the encoder, and would not be sent to the decoder. It could be carried in an ancillary data 
stream in a wider bandwidth network distribudon system. 

Scene Change: 

Automadc scene change detection algorithms arc used in some encoders to improve coding 
efficiency. There has not been an interface specified for this informanon to be transmined to the 
encoder, but it would aid in the coding algorithm. Such scene change informadon* if supported by 
a production facility, could provide useful information to the video encoder at both the 
compression and transpon levels and we look forward to working with standards bodies to make 
this effective. 

Conditional Access Identification: 

Implementation of Conditional Access systems is supponed by the transport syntax, with bits 
defined in the packet header. Delivering infomiarion about the conditional access infonmtion, 
including key information is an issue that would be addressed as private data in the GA syntax. 
This issue is covered further in a separate chapter on Conditional Access. 

Universal Identiner: 

Definition of Universal Identifier infomiation has not yet been finalized by SMPTE. The issue of 
the registration descriptor is addressed more completely in chapter 9. 
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5. The Transport format and protocol 

This chapter defines the syntax elements for the iranspon layer of the GA bit stream. All syntax 
elements need to be recognized at some level in a GA receiver. Most trigger a response in the 
transport decoder. A few arc present for interoperability with MPEG-2. 



5.1. Link level headers 



(0x47) 



13 bit PIO 



Adapcauon header 
or 

Packet Pavload 



J] 



1 bit - tpansport_priority 



1-bit - payXo<id_unit,start_indicator 
1 bit - transport«packct_errop.indicator 

Fig. 5,1. Link header format for the GA system transpon packet. 



I 4 bits - continuity.counter 
^ 2 bits • adaptation.fi el d.control 
2 bits - transport^scromblinflLControl 



Fig. 5.1. shows the link layer headers with the functionality assigned to each bit. Some of these 
have been discussed earlier. The table below spells out these functions in detail. These general 
fiinctions may not all be used on the broadcast channel, but are useful for transmitting the same bit 
stream over other links, including cable links, computer networks, etc.. In short, these provide 
interoperability features. 



field 


General function | GA usage 


Sync byte 

Value- 0x47 


Packet synchronization. 


As defined. See section 2.1.1. 


indicator 


Indicates if packet is erroneous 

0 - no error 

1 - erroneous packet 


Ca^ be used for error signaling 
from modem to transport 
demultiplexer. If this bit is set 
the payload is not supposed to 
be used. 


indicator 


Indicates if a pes packet header or the start of a 
table containing program specific information 
(PSI) is present in the payload in this packet 
The PES packet header always begins the payload 
of the packet. The starting byte of the PSI table 
in the packet is indicated using a pointer field to 
be descibed later. 

0 - no PES header or start of PSI table present 

1 - PES header present 


As defined for resynch into the 
transport suxam. 



Grand Alliance HDTV System Specification 

Page 27 

»B0OCID: <XP___2055175A_L> 



Draft Document 



Tranxpnrt System 



tnnspon_pnoruy 


Prioricy indicator at input to transmission 
ciiannels/networics which support pnonuzauon. 
u - lower pnoncj 
I - higher priority 


The GA transmission system is 
ciuicuuy noi expocieo lo 
cimrwt nrtnHtiTiittnn TF if 

does, this bit will be set during 
cranspon 

packctizadon process, to route 
packets to the transmission 
oflth with the annrDnridtA 
oriority. 


"TO 


Packet Identifier for mux/dcmux. 


As defined. See section 2.1.2. 


tnnspon.tcnmouog. oonuol 


Indicates the descrambling key to use for the 
packet 

w - not scrantoiec 
others - user defined. 


00 - not scrambled 
10- "even" key 
11* OQQ jcey 

01 - reserved 
See section 2.1.4. 


AOApuuon.i teio .conirol 


Indicates if an adaptation field follows 
00- reserved 

01 • no adaptadon field, payload only 

10 - adaptation field only, no payload 

1 1 - adaotation field followed bv oavload 


As defined. 


oonun uiiy _couni« r 


Increments by one for each packet with a given 
truj diiu uoiupuii pnunijr* usco oi uic occoucr ttj 
detect lost packets. Not incremented for packets 
with adaptadon field of 00 or 10. 

If two consecuQve tianspon packets of the same 
PID have the same oondnuicy.councer value and the 
•lUpttiion.rieid.oontroi equals "Or or 'ir, the two 
transDon t^ackets shall be considered duolicate. 


As defined. See section 2.1.3. 



5.2. Adaptation level headers 

The presence of the adaptation header field is signaled in the adapiadon.field.conorol of the link layer 
as described before. The adaptadon header itself consists of informarion useful for higher level 
decoding funcdons. The header format is based on the use of flags to indicate the presence of the 
particular extensions to the field 

The header starts with a fixed length component that is always present (if an adaptation header is 
transmitted). The format is shown in Fig. 5.2. 



Grand Alliance HDTV System Specification 

Page 28 



Draft Document 



el einentary_stream_priort ty_i ndt color 



dt sconti nut ty_\ ndi cator 

1 


OPCR,Aog 

1 transport^i 


•ivate.data^flog 






flagged adaptation / 
header fields / 


1 . 

random.acces5_indi cator 


1 adaptation^field.extcn$ion_flag 
spl i ci ng_poi nt.fl ag 



PCR.flog 

Fig. 5.2. Format for the fixed length component of the adaptation header. 

The adaptarion.fieldjengih specifies the number of bytes that follow it in the adaptation header. The 
adaptation header could include stuffing bytes after the last adaptation header component field. 
(Stuffing bytes have a value of Oxff and are not interpreted at the decoder.) In this case the 
adaptadon.field Jength also reflects the stuffing bytes. The value in the adapiarion.field Jengih field can 
also be used by the decoder to skip over the entire adaptation header, and to directly advance to the 
data payload in the packet if desired. 

The presence of additional adaptation header fields is indicated by the state of die last five single bit 
Hags shown in Fig. 5.2. (with a value of T indicating that a particular field is present). The three 
flags at the beginning do not result in extensions to the adaptation header and arc described in the 
table below. 



field 


General function 


GA usage 


auconunuity_ui<iicaLor 


Indicates if there is a discontinuity in the PGR 
values thai will be received from this packet 
onwards. This happens when bit streams are 
spliced. This flag should be used at the receiver 
to chancre the phase of the local clock. 


As defined for local program 
insertion. See section 2.13. 


randocn.iccess.Lndicaior 


Indicates that the packet contains data that can 
serve as random access point into the bit stream. 
As an example, these can correspond to the start 
of sequence header infonnation in the GA video 
bit stream. 


As defined. See section 12.2. 


elcmcfMAry^ttreim _ 
p rioKcy.indtcator 


Logical indication of pnority of the data being 
transmitted in the packet 


Not used. If set it is ignored at 
a GA decoder. 



As mentioned earlier, the other components of the adaptation header appear based on the state of 
the flags shown in Fig. 5. The order in which these components appear in the bit stream is the 
same as the order of the flags. Based on the type of ada^jtation header information being 
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conveyed, the data in these fields may be cither fixed length or variable length. These fields are 
described in detail next 

5.2.1. The PGR and OPCR fields 

The use of the PGR has been described in detail in section 2.2,1. This section deals mainly with 
the fonnat for transmission. 



Overall Format 



Coriginal.)program.clock_reference_extension 
I 



33 bits 



6 bits 



9 bits 



reserved 

( ori gt nal .)program.cl ock_ref crence.bose 

Fig. 5.3. The (O)PCR header format. 



FuntTionalitv 



field 


General function 


GA usage 




Indicates intended time of arrival of lost byte of 

the pfogrtfn.dodc. 

nf erenee.cxiensioa at target decoder. Used for 
synchronization of the system decoding process. 
This field can be modified during the 
transmission Droeess. 


As defined- The pgr will be 
uansmioed at least once every 
100 milliseconds. 




Indicates intended time of arrival of last byte of 

the angina] jnognm. 

ciock.reference.atension at target deCOder for a 

single program. This field is not modified 
durine transmission. 


May be used for recording and 
playback of single programs. 
Not used in the GA receiver in 
the decoding process. 



Fimctinnal dernil^ nf ihe (0\PCR fnrmat 

The total PCR value is based on the state of a 27 MHz clock. The 9 bit extension field cycles from 
0 to 299 at 27 MHz, at which point the value in the 33 bit field is incitmenied by one. (This 
results in the 33 bit field being compatible with the 33 bit field that are used for the 90 KHz clock 
of MPEG- 1. Backward compadbility was a concern in the MPEG-2 system design.) The cycle 
time of the PCR value is approximately 26 hours. 



S.2.2. The transport_privatc_data and adaptation^field^extension fields 

Emm 
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1 byte length 
Held (0 



transport.private.dato 
or 

odap t ati on.fi el d.ex tensi ons 



/ bytes 



Fig. 5.4. The Dansport_privaie_dataand adaptation_fleld.exteiision header fonnat. 
Fiinrrinnalitv 



field 


General function 


GA usage 


tnnspoctj>nvaie.(Uu 


For private data not recognizable by the general 
MPEG decoders* Meant for short btirsts of 
control informadon. 


Tobe decided 


extmtions 


For fuQut extensions of the adaptation header 
which may have not been thouscht of yet 


Not used cunendy. 



5«2.3. The splice^countdown field 

This field is useful for local program insertion as described in section 2.23. 



Format: This is a one byte field that is present if the splicingj)oint.flag is set 



Fimaionality 



General Function 


GA Usage 


Indicates number of packets present in the bit stieam, with the same PID as current 
packet* until a splicing point packet. The splicing point packet is defined as the 
packet containing a point in the elementary bit stream from which point onwards 
data can be removed and replaced by another bit stream* so that the resulting 
tnmspon bit scream is valid according to MPEG-2 rules. Transmitted as a 2s- 
complement value. 


Used for supporting insertion 
of local programining. 



S3. PSIs and the pointer.field 

As mendoned in chapter 3, the program.associauon.iable and the progiam.map.iables that describe the 
organization of a muldplexed GA bit stream are a part of the PSI layer of the GA system. PSI 
lablcs, in general, are transmitted in the appropriate bit stream sequentially, without any gap 
between the tables. This implies that tables do not necessarily stan at the beginning of a transpon 
packet. This also implies that in order to decode specific tables, there needs to be some indication 
of where these begin in the bit stream. This functionality is achieved widi the pointer.ficld. The 
pointer_field, if present, is the byte of the payload of a packet (after the link and adaptation headers). 
The pointer.field is present in the packet if a PSI table begins in the packet, an event which is 
signaled at the link level, by setting the payIoad.unit.siart.indicator (described in section 5.1) to 
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The pointcr.field indicates the number of bytes that follow it before the stan of a PSI table. As an 
example a pointer.field value of 0x00 indicates that a new PSI table begins immediately foUowing it 



5.4. The program_associatioii_table 

As discussed in secdon 3.2, the program.assodaiion.table is transmincd as the payload of the bit 
stream with PID = 0 and describes how program numbers associated with programs, (e.g., 
HBO"'^*'^, ESPN™, etc.) map on to bit streams containing the program.map.tables for these 
programs. This section discusses the syntax of the table in some depth. The 
program^associauon.table may be transmitted as multiple program.associadon.segments with each 
segment having a maximum length of 1024 bytes. The iranspon decoder can extract individual 
table segments from the bit stream in whatever order it desires. As shown in Fig. 5.5. each table 
segment has a fixed length 10 byte header component for table segment identification, a variable 
length component tiiat depends on the number of entries contained, and a 4 byte CRC-32 field, 

4byicCRC-32 
nailer 

J- 



8 bytes 
overall header 



variable length program table list 



Fig. 5.5. High level overall picture of the program.association.segment 



i. The fixed length ovcraU header component is shown below in Fig. 5.6 and is described in the 
cable below. 



secti on_l ength 5 bits • ver sion^number 

2 bits, value := UO* I 2 bits - reserved I section.number 

J 1 — L i ' 



I byte 



table.id 
(0x00) 
2 bits - reserved 



12 bits 



16 bits 



T 



1 byte I byte 



T 



Variable length 
program association list 



cransport_Streani_id | last_section_nunbep 

I bit- current_next«indicator 



Fig. 5.6. Fixed length header component of the program.associaiion.taWe. 



field 

uoie.ia 



General function 



usase 



Indicates the nature of the table, 0x00 indicates a 

pfotntfn_«i>odauonjible 



As defined. 
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secaonJengU) 


Length of the section of the 
p(otnm.usociati<».ubie. This length includes all 
bytes following this Held, up to and Including 
the CRC. The two most significant bits of this 
field are set to 0, i.e., maximum value is 1024. 
This field allows the transport decoder to slop 
secdons when reading from the bit stream if 
desired. 


As defined. 


"Tranjpoei_iircam_id 


Identication of a particular multiplex from 
several in the network. 


Should correspond to a channel 
number for the terrestrial 
application. 


venKMi.number 


Incremented each dme there is a change in the 

prognun.Auoditioa. 
able beinff transmitted. 


As defined 


curreni.n ut^tnd ica tor 


Value of I indicates that the map is cuntndy 
valid* Value of 0 indicates that the map is not 
currendy beini; used and will be used next 


As defined 


sccuon.number 


Identifies the particular secdon being 
transmitted. 


Asdefined 


Usi.secuon^umber 


Section^number for the last section in die 

pfogiiin.itsocittion. 
ubic Needed to confirm when an 
entircpragnro.uiodtdan.tabie has been received at 
the decoder. 


As defined 



The value of the reserved bits is undefined and die GA system should not interpret these. On the 
odier hand the 2 bit '10' value following the table Jd needs to be received correctly. 

ii. The variable length component of the table consists of programjcount number of fixed length 
entries corresponding to each program, and stuffing^bytcs (to make up the 
ptogram.associadon.segmentjength). The format for each fixed length entry is shown in Fig. 5.7. 

reserved 



16 bits 
program.nufflber 



3 bits 



13 bits 



marker bit 



T 



Mctwork^PIO or progpom^ap.PID 

Fig. 5.7. Format of each entry in the program.associadon.tabte. 



The program identity '0' is reserved for die network.PID, i.e., die PID of the bit stream carrying 
information about the configuration of the overall system. The nature of this bit stream is yet to be 
defined for the GA system. The forniat for this bit stream is completely open since it is meant to be 
a private bit stream. For all other program identities, die program.map_PID is die PID of the bit 
stream containing the progTam_map_table for the particular program. 



Grand Alliance HDTV System Specification 

Page 33 



Draft Document 



iii. The program.asscxiadon.table ends with a four byte CRC field that contains results of a CRC 
done over the entire pro gram map segment, starting at the segment.scvt.code jirefix. The CRC is 
based on the polynomial x3^x26+x23+x22+x^64.xl2+xll+xl0+x8+xVx5+x^-hx2+x-Hl. 

5.5. The program^nap^table 

As discussed in the previous secdon, the prognm.map.table is transmitted as the payload of the bit 
stream with PID = pragram.map.PID (as indicated in the program.associadon.cable). The 
program.map.table carries infonnadon about the applicadons that make up programs. Basically each 
program^map.table is transmiaed as a single TS jrogxam.map.secdotu The fonnat for a 
TS jmgram.map.section can be described as a combinadon of an overall header field, fields that 
describe each program within the table and a trailer CRC field, as shown in Fig, 5.8. The CRC 
used is the same as for the prograin.associauon.table. In general, each pnjgram.map^PID may contain 
more than one TS j>rogiam.map_section, each describing a different [ii i' > t»r s i rp 

4byicCRC.32 
txaiJer 



1 12 bytes 


vahabte length 




I overall header 


singic program descripdon 


1 



Rg. 5.8. High level overall view of the IS jjrognrni.map.section. 
S.5.I. The overall TS j>rograni_m3p_segmeot header format 

The header format for a IS jTOgram.fnap.secdon is shown in Fig. 5.9. The format of the fint 8 
bytes is the same and has similar functionality as that for the progiaro_as$ociaaon^iablc. The similarity 
in format is intended to facilitate simple software decoding of the headers. Note that the table.id for 
TS jjiogiani.niap.secrion is different from that for the program.assoctadon.table. 



section.lcngtti 
Ibtcs. valuer 10' 



5 biu * vtrsioit.nunber 



2 biu > reserved 



3 bitt - reserved 4 biu - reserved 



Ibyie 



12 biu 



"T — 

(0x02) I 
Zbtu - reserved 



16 biu 



2bytes 
(0x0000) 



pro gnm .number 

I bit - current. f>ext» indicator 



13 biu 



12 biu 



Vihatoie length 
pf9grun descnption 



Fig. 5.9. Fixed length header for the TSjjrogiam.map.scction. 

The two bytes that were used to idendfy the transpon^stream.id in the associadoa table are now used 
to identify the prognun.numbcr of the program whose description foUows. Tbc seaioo identification 
ftmcdons are not required for this table since the description of each program is defined to have to 
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fit into one sccrion. Hence these fields are set to '0' as shown in the figure. The other conimon 
header fields between the program^association^nblc and the TS j»ogram_inap.section have funcdonality 
as desecribcd in die table following Fig. 5,8. The addirional header fields in a 
TS jjrograni.map.soction are the 13 bit PCR.PID field that identifies the PID of die pairicular packcrizcd 
elementary bit sucam in die program that contains the PGR values for the program, and die 
prognun_infojcngih field, diat indicates the number of bytes of program.dcscripms diat follow this 
header field 

The overall program description diat follows die header described above consists of die optional, 
variable length, program.dcscriptor field (whose Icngdi was indicated by die program.infojcngih field 
shown in Fig, 5.9), followed by a descriptions of each of die individual elementary bit streams diat 
make up the program, i.e., there are one or more elementary bit stream descriptions for each 
TSjTrogram.map.sccuon. 



5*5*2 An elementary stream description 

Each elementary stream description for has a 5 byte fixed length component and a variable length 

elemeniary.stream.descripcor component as shown in Fig. 5.10. 
reserved reserved 

1 



1 byte 



T 



■3" 

2 
«n 


13 bits 


14 bits 1 


12 bits 



I 



additional, variable length, 
elementary stream desciiptocs 



IfLi 



«leflentary^IO 
strctfB.typc ES.info.length 



Fig. 5.10- The fixed length component of die elemcncaiy stream description. 
The fimcdonality of the different fields is as follows. 



tield 


General function 


GA usage 




Indicates the application being considered b this 
elementary stream. 




etonenuiy^ut 


Indicates the PiD of the transport bit stream 
contatninir the elementary bit scream. 


Asdeftned 




Indicates (he length of a variable length 
deaiaiunr.nram.(iescnp(or field that immediately 
follows. 


AsdeBned. 



As before reserved bits are ignored. 
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5.6. Descriptors 

Descniptors are Dransmittcd in the program.descriptor and the elcmcntary_sircain_dcscripior fields to 
describe certain chaiaacterisidcs of the program or the elementary bit stream. In general, each 
program.descripior and the elcmcntary.streafn.dfiscriptor can consist of number of individual descriptor 
field elements transmitted sequendally. 

Two facton need to be considered in order to use descriptors. In the first place, there has to be an 
mechanism for indicating the presence of the descriptors. In the PSI tables that have been 
described, this funcrionaiity is achieved by the length field that preceeds the descriptor, with a 
value of zero indicating that no descriptor are present. A second function is the identification of the 
descriptor itself. This is achieved within the descriptor header itself, which consists of a one byte 
dcscriptor^iag field followed by a one byte descriptor Jength field that specificies the number of byies in 
the descriptor following the descriptorjengih field. The set of valid descriptor_iags in the GA systems 
is the same as that defined for MPEG-2. The table of tags and the format for each descriptor are 
not described in this documenL 
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6. The PES packet format 

As described before, some elementary bit streams* including the GA video and compressed audio, 
will go through a PES layer packedzation prior to the GA transport layer. The PES header carries 
various rate, timing, and data descriptive information, as set by the encoder The PES packerizarion 
interval is application dependent. The resulting PES packets are of variable length with a maximum 
size of bytes, when the PES packet length field is set to its maximum value. This value is set 
to zero for the GA video stream, implying that the packet size is unconstrained and that the header 
information cannot be used to skip over the particular PES packet This value of Note also that the 
PES packet format has been defined to also be of use as an input bit stream for Digital Storage 
Media (DSM) applications. Although the DSM format will not be used for GA broadcast 
application, some of die PES header fields related to the DSM functions are also described in diis 
chapter. Note that die ability to handle input bit streams in the DSM format is not essential for a 
GA receiver, but may be useful for VCR applications. 

The constraints on the length of the PES packets for GA video have to be setded upon. Among die 
decisions to be reached are whether PES packets should only start on GOP boundaries, whedier all 
GOP boundaries should stan a new PES packet, whether PES packets should be defined for each 
access unit (corresponding to a picture), etc.. Note that the format for carrying the PES packet 
within the GA transport is a subset of the general definition in MPEG. This choice was made to 
simplify the implementation of die GA receiver. Essentially, in the GA transpon system, all data 
for a PES packet, including the header, are transmitted contiguously as die p^^load of transpon 
packets. New PES packet data always stans a new transpon packet, and PES packets that end in 
the middle of a transpon packet arc followed by stuffuig bytes for the remaining length of die 
transpon packet. 

A PES packet consists of a PES j)ackei_start_codc, PES header flags, PES packet header fields, and a 
payload (or data block), as shown in Fig. 6.1. It is created by die application encoder. The packet 
payload is a stream of contiguous bytes of a single elementary stream. For video and audio 
packets, the payload is a sequence of access units from die encoder. The access units correspond 
to the video pictures and audio frames. 

Vartabte 
Ltngth 



3bytes 


I byte 


2byta 


2 bus 


14 bib 


Ibyte 


, ^, N , 


I Packet sun 
1 CodePrefbc 


Stream ID 


PES Packet 
length 


10 


PES Header 
Flags 


PES Header 
Length 


PCS Header! PES Packet Data Block 
Fields 1 J 
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Figure 6.1. Structural Overview of a PES Packet 

Each elementary stream is identified by a unique stream Jd, The PES packets firom each encoder 
carry the corresponding scream.id. PES packets carrying various types of elementary streams can be 
multiplexed to form a program or transport stream in accordance with Pan 1 of the MPEG-2 
standard. This chapter deals with the organization of PES packets for MPEG-2 compliant streams 
only. Specifically, the stream Jd field can take on a number of values* indicadng the type of data in 
the payload (See Table for valid values). This secdon docs not define the PES packet smicturc for 
'private data\ i.e. stream Jd must be 'Reserved*, Tadding', or *MPEG Audio' or *MPEG Video*. 
For 'private data\ the PES packet soructure is user defined. 



The preliminary fields, the packet^siart.codcjjrcfix, stream Jd, and PES jjackctjcngth, are described in 
the table below. 



Held 


1 Descriodon 


1 GA Usage 


paacei_iun.coo«_prexu 


Indkaies the stan of a new packet. Together with 
the tuuun.id, it forms the p«ckei.tun.code. Takes 
on the value 0 x 00 00 01. 


Asdetlned 


siieam.id 


Specifies the type and number of the stream, to 
which the packet beiongs. 

10111100 - Reserved Stream 
1011 1101 - Private Stream 1 
1011 1110 - Padding Stream 
1011 nil - Private Stream 2 
llOxxxxjc - MPEG Audio Stream 

Number xxxxx 
lllOxxxx - MPEG Video Stream 

Number xxxx 
1111 xxxx - Reserved Data Stream 

Number xxxx 


Asdefmed 




Specifies the number of bytes remaining in the 
packet after the this Field. 


0 X 00 00 - Only allowed 
value for video. 

Details for audio yet to be 
detennirted 



6.1. PES header Flags 

A breakdown of the PES header flags is shown in Figure 6.2. These flags arc a combination of 
indicators of the properties of the bit stream and indicators of the existence of additional fields in 
the PES header. The following table describes the flags present the header. The flags not supports 
by the GA system are set to '0* and form the basis of some of the "constraints" discussed earlier. 
(These entries are shaded in the table.) Note that the abbrcviadons in the tables are from the flag 
names in Fig. 6,2. 
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PES Header K// 
Flags 




RATE I TM I AC I CRCj EXT 



ESCR 



Figure 6.2. PES header flags in their relative positions (all sizes in bits) 
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Plair 1 Description 


GA Usage 


'•-xS^j • !'V' : '* • : -> - :;* ? * • -i . • = • ' ■ •'. iv: 






PESjmonry 

(PR) 


Indicates ihc priority of this packet with respcci 
to other paclcets whose PR field is not scl 

1 - Higher priority 

0 — Same priority 


GA does not care how this field 
is set. flt may be used by 
appiicadons where necessary.) 


(Uu alignment tndicsior 

(DA) 


Indicates the nature of alignment of the first 
start code occurring in the payload. The type 
of data in the payioad is indicated by the 

dau.tvcmm.ftlifnmcni.deschpusr. 

I - Aligned 

0 - No indication of alignment 


Must be aligned for video. To 
be decided for Audio. 


CQpynght 

(CR) 


Indicates the copyright nature of the associated 
PES packet payload. 

1 - Copyrighted 

0-Noi coDvriehted 


The Ga has yet to define its 
use of this field. 


ohfinal.or_copy 

(OC) 


Indicates whether the associated pes packet 
payload is the original program or a copy. 

1 » Original 

O — CotTv 


The G A has yet to define its 
use of this field. 


PTS.DTS.fUgi 


This flag indicates whether the PTS or PTS and 
DTS are in the PES header. 
00 - Neither PTS nor dts 
is present in header. 
IX" PTS field present 
11 - PTS and DTS field 
preseni in ncooci. 


The PTS flag is set when video 
daia alignment indicator is seL 
The DTS may be included to 
signal the decoder of any 
special decoding requirements. 
The PTS transmissions should 
be spaced less than 700 msecs 
aoan. 




fflndkratesi^lAt^^^^ 
^T^eferenSSftii^a^ 


liSefei^^ Ji. 




::iixiicateS:W.ncuier.ui&iit^^ 
iificlii^iiisennn-t^^ 




•^aL> aaajuiA fl V >■ 

USM _'.nck .mofl c _I ug 

CIM) 


Indicates (he presence of an 8 bit field 
describing the mode of operauon of the DSM 
(Digital Storage Media). 

1 - Field present 

0 - Field not present 


Set to '0' for the broadcast 
transmission. May be used for 
trick modes when using bit 
streams specifically generated 
for VCR tvpe oocrauons. 


1 ftddiiuonAi.copy.uuo.tug 

(AQ 


Indicates the presence of the »d(iiaoiui_copy_inro 
field. 

1 - Field Present 


The OA has yet to define its 
use of this field. 


iiiCCRC). ':V t.:,;;:v:;.. .. 


::Indihucs;whether.a::CRe: fic 
•■PESt)acketi=;::=i=^ 




FbS_£xientionjU( 


This Hag is set as necessary to indicate that 
extension flags are set in the pes header. Its use 
includes support of private data. 

1 - Field present 

0- Field not present 


As defined. 
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6.2. The PES header 

The PES header immediately follows the field PES.hcaderJcngth, which indicates the header size in 
bytes. The size of the header includes all the header fields, any extension fields, and stufrmg_byics. 
The flags described in the previous section indicate the organizarion of the PES header, Le. which 
fields it does and does not contain. In essence, all the fields of the PES header arc optional. 
Certain applications require particular fields to be set appropriately. For example, GA transpon of 
video PES packets requires that the daia^alignmcni^indicaior be set The trick mode flag is not set in 
this case. For DSM retrieval of video, the opposite is true. It is the application encoder's function 
to set the appropriate flags, and encode the corresponding fields. The fields are funher described 
in the following sections. The association between the flags and the corresponding fields is 
obvious. 



PES Packet Data Block 




PTS 
DTS 



DSM Tttck 
Mode Field 



Additional 
Copy Info Field 



PES Extension 
Flags 



Extension 
Data Held 



Stufllng 
Bytes 



Figure 6.3, Organization of PES header. 



The PES header Fields are organized according to Hg. 6.3 for the GA PES packets for video 
elementary streams. Most fields require marker bits to be insened, as described later, in order to 
avoid the occurrence of long strings of O's which could resemble a stan code. 

PTSandPT!! 

The prcscntation_tifne_stamp (PTS) infonns the decoder of the intended dme of presentation of a 
presentation unit, and the decodinj_tinie_stamp (PTS) is the intended time of decoding of an access 
unit An access unit is an encoded presentation unit When it is encoded, the PTS refers to the 
presentation unit corresponding to die first access unit occurring in the packet. If an access unit 
does not occur in a res packet, it shall not contain a PTS. Here, a video access unit is said to occur 
if the first byte of the picture start code is present in the PES packet payload, and an audio access 
unit occurs if the first byte of the synchronization word of an audio frame is present Under 

Grand Alliance HDTV System Specification Draft Document 

Page 41 

(NSDOCID: <XP 2055175A_L> 



Transport System 



normal conditions, the DTS may be derived from the PTS. So, it is not required to encode the DTS. 
Cbnscqucndy, encoding the DTS may indicate special decoding requirements to the decoder. 
Under no circumstance does the DTS occur by itself; it must occur along with the PTS although the 
converse is not true. The PTS field is organized as shown, if it present without the DTS. 



4 bits 



36 bits 




PTS 


marker 


PTS 


marker 


PTS j 


marker 


32 ... 30 


bit 


29 ... 15 


bit 


14 .„ 0 1 


bit 


3 bits 


Ibit 


15 bits 


Ibit 


15 bits 


t bit 



Figure 6.4. Organization of the PTS field when only the PTS is encoded 
If both the PTS and DTS are sent, the following organization is required. 



4 bits 


36 bits 


4 bits 


36 bits 


0011 


PTS 
Field 


0001 


DTS 
Field 



Figure 6J. Organization of the PTS and DTS field when both PTS and DTS are encoded. 
Here, the DTS field is defined in the same manner as the PTS field. 
DSM Trick Mnd^FiP.l^ 

The DSM trick mode field is an eight bit field, indicating the nature of the information encoded in 
the PES packeL The first three bits of this field form the identifier trick.mode.control. indicating the 
nanire of the DSM mode. There are four modes to the DSM, as summarized in die table below. 



It IS emphasized once again ihai the ability lo deal with trick mode bit streams is not 

a basic requirement for a GA receiver and this description is here only for 

completeness. This field is not present in the broadcast GA bit stream. Since the 

objective m this document is not to describe in detail the DSM mode of operation, all 

that IS presented is the DSM syntax with some description of the respective fields. For 

more detailed information the reader is directed to the MPEG-2 Sysesns document. 
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Value 


Description 


'COO* 


FastFbrwaid 


'OOr 


Slow Motion 


•010' 


Freeze Frame 


'Oil' 


Fast Reverse 


*lxx" 


Reserved 



DSM Trick Modes 

Depending on the value of trick.mode.control, a combination of four identifiers arc encoded as 
described in the table below. 



Identifier 


Description 




This identifier is valid for interlaced pictures only. It is a 2 bit field which 
idendfies how the current frame is to be displayed, 

*00' ^ Display field 1 only 

*0r- Display field 2 only 

*10' - Display complete frame 

•ir-Rcscrvcd 


f requency.tnincaicioa 


This 2 bit field indicates the selection of coefficients from the DSM. 
'00' - Only DC coefQcients are sent 
*0r - The fiist three coefficients in scan order on average 
'10' * The first six coeflicients in scan order on average 

This field is for infonnational purposes only. i.e. the DSM may at times send 

more than the specified number of coefficients and at other dmes less. 

However, that infonnation is not normative. 


imn_i Uce.rcf res h 


This 1 bit field indicates that each picture is com(x>sed of intra slices with 
possible gaps between them. The decoder should replace the missing slices by 
reoeatins the colocated sites &om the orevious decoded oicture. 


field_rep_cnul 


This field indicates how many dmes the decoder should repeat field U\ as both 
top and bottom fields altemadvely. After field #1 has been displayed, the 
decoder should repeat field #2 the same number of times. This identifier being 
set to 0 is equivalent to a freeze frame with field id beine set to * 10'. 



Fast Forward and Fast Reverse Modes: The format in this case is shown in Fig. 6.6, The 
decoder is told how many coefficients arc encoded, how the fields are to be displayed, and 
how to replace any missing slices in the access units* 



tricJcjnode 
control 


field_id 


intra_slice_ 
refresh 


frequency^ 
tiruncation 


3 bits 


2 bits 


1 bit 


2 bits 



Fig. 6.6. Trick Mode Field in Fast Forward 
and Fast Reverse Modes 

Slow Morion Mode: In this mode, the DSM inforais the decoder how many times a particular 
field is to be repeated. The identifier field.rcp_cnirl is encoded as shown. 
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trt'Ck^mode^ 


fleld_rep_ 


control 


control 


3blt3 


5 bits 



Fig. 6.7. Trick Mode Held in Slow Morion Mode 

Freeze Frame Mode: Only the idenrifier is encoded in this mode. It indicaies to the decoder 
how to display the frozen picnirc. The field is organized as shown in Rgure 6.8, 



trlcJc_mode_ 


field^id 


Reserved 


control ^ 






3 bits 


5 bits 


5 bits 



Rg. 6.8. Organizarion of Trick Mode Field for 
Freeze Frame Mode, 

AMnonal Coi?^ Info 

This is a one byte field with a marker bit up front and 7 bits of information. The use of these seven 
bits is yet to be deteraiined. 



PFS Extenmn Flass 

The header could contain additional flags if the EXT flag (shown in Fig. 6.2) is set. These flags 
are transmitted in a one byte data field as shown in Fig. 6.9, 



PES prtvate 
data flag 


pack header 
fleld flag 


program packet 
sequence counter flag 


STD Buffer 
Flag 


Reserved 


PES extension 
fleld flag 


1 bit 


1 bit 


1 bit 


1 bit 


a bits 


I bit 



Figure 6.9. Organization of the PES Extension Flags Field. 

The flags indicate whether further extensions to the PES header exist. The table below describes 
the nature of this additional data. As with the flags defined previously, the flag is set to * T if the 
header field is prcscnL 



Field 


General Description 




llndicates-: whether' tfePESijadc'et^^ 








decad^^to*jetrievt;tbG.pa£i££te0^ 






mfiS.exteasion^add.nig 


Indicates thepitsenccof additiooaldacitBFeSteader. 
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For the GA system, as indicated in the constraint document submitted to MPEG, die flags that are 
shaded in the table are always set to *0'. It is likely that the EXT flag will set to '0' in the header 
flags field unless there is infonmarion to be transmitted in the PES.cxtcnsion.ficId, This field is mean 
for funcdons that may have been missed in the inidal design specification. 

PFS Exten^inn Field 

This field is shown in Fig. 6,10. The length of the PES.cxicnsion^field data is given by 
PES.cxicnsion.fieldJength, 



marker 


PES Elxtenslon 


Reserved 


bit 


Field Length 




I bit 


7 bits 





Figure 6. 10. Organization of the Extension Field 
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7« Conditional Access 

The transport protocol implements functions useful for supporting conditional access. The 
functionality that is available is flexible and complete in the sense of supporting all transmission 
aspects of applicable key encrypdon and descrambling approaches that may be used- Conditional 
access is also flexible in the sense that it can be exercised on a elementary stream by stream basis, 
including the ability to selectively scramble bit streams in a program if desired. 

A conditional access system operates on the principle of randomizing the transmitted data so that 
unauthorized decoden cannot decode the signal Authorized decoders are delivered a "key" which 
initializes the circuit which inverts the bit randomization. In subsequent discussion, we use the 
term scrambling to mean the pseudo-random inversion of data bits based on a "key" whiph is valid 
for a short time* We use the term encryption to mean the process of transforming the "key" into an 
encrypted key by a means which protects the key from unautiiorized users. From a cryptographic 
point of the view, this transformation of die key is the only pan of die system which protects the 
data from a highly motivated pirate. The scrambling portion of the process alone, in the absence of 
key encryption, can be defeated. Conditional Access (CA) is a blanket term for the system which 
implements the key encryption and disttibution. The primary requirements which a scrambling and 
CA subsystem must meet for digital TV delivery arc: 

• Protection of programmer's revenues 

- robust against piracy. 

Private encrypdon system for each program provider. 

Standard consumer instruments 

- no secrets in consumer equipment 

Mobility of consumer equipment 
. Consumer equipment should be cost effective 
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7.1. General Description 

There are two features of the GA Transport system which support conditional access. The fini 
feature is the two bit tiansport_scnunbIing_contiol field which signals the decoder whether the transpon 
packet was scrambled or not In the case that it was scrambled, the field identifies which 
scrambUng key was used. As will be shown shorUy, the use of two bits in the 
.ransport.scrambUng_contn)l to define the descrambling process is a necessary and sufficient bound for 
the key distribution function. The second feature is the abUity to insen "private" data at several 
places in the GA Transport stream. These include entirely private streams and private fields in the 
adaptation header of the transpon bit stream being scrambled. These private fields can be used to 
transmit the encrypted scrambling key to the decoding device. 

The key distribution and usage process is clarified in Fig. 7.1. BasicaUy, when die bit stream is 

scrambled, one descrambling key needs to be in use while the other is being received and 

decrypted. Two keys are transmitted at any time, with the keys being linked to a 

tianspon.scrambling_conmj! value as shown in the figure. The transmission of a key should begin 

weU before it is going to be used, to allow time to decrypt it. Note that this function does not 

bound the total number of keys diat may be used during an entire transmission session. 

time 



descrambling 
keys transmitted 

in trusport 
biutream for key 

distribution 



11 
10 



headers for the 
elementaxy bit stream 



descrambling 
key used 
on packets 



key(i) 



lcey(i-l) 



transport_scroiBbl i ng. 



keyCi-^2) 



key(i+l) 



key(i+4) 



key(i+3) 



key(i+5 







10 


n 


1 


10 


11 



tey(i-l) } ; keyO) | kcy(i^-l) | kcy(i-^2) | 



icey(i+3) 



kcy(i+4) 



Time available to pick up 
key, feed to a smart card 
and to decrypt it 



Fig. 7.1. Illustration of key distribution and usage process. 
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As stated previously, the amount of data to be scrambled in a packet is variable depending on the 
length of the adaptation header. It should be noted that some padding of the adaptation field might 
be necessary for certain block mode algorithms. 

7.2. Example of Conditional Access Implementation 

In this section, we go through a simple example of a conditional access implementation. Consider 
the receiver architecture shown in Figure 72. The high speed manipulations required to implement 
the dcsciambling arc embedded in the transpon demultiplexer, where they are shown as a DES 
block. Note that other scrambling schemes, such as stream ciphers based on a Pseudo Random 
Binary Sequence (PRBS), could be employed The PRBS uses a shift register implementation, 
where it the initial register value is reset periodically for error robusmess. The data security is 
achieved by the "key" which properly configures the descrambler. This element is delivered to the 
decoder through an ancillary data service, and is encrypted by the conditional access administrator. 
In the equipment at the customer's premises, the key is decrypted within the outboard Sman-Card 
The Sman-Card interface will conform to ISO standard ISO-7816, which permits a variety of 
implementations and conditional access soludons. 

The Sman-Card maintains a shon list of two key's, commonly denoted as the "odd" key and the 
"even" key. The proper key to be used to descramble is signaled in the transpon prefix in the 
cransport_scranibling.control field. The transport.scramblin^controi takes on one of the following 4 
States: 

iransport.scrambling^control Description 

00 Not Scrambled 

01 Reserved 

10 "even" key 

11 "odd" key 

The scrambling in this example is a block cipher called the "Electronic Code Book" mode of the 
Digital Encryption Standard (DES), For DES, the key is a 56 bit binary sequence. The television 
electronics are "standard", while the Sman-Card implementation is proprietary to the service 
provider. 
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Rg. 7.2. Decoder with Example Conditional Access Implcmcntarion 



There is significant flexibility for multihop encryption and nesting of encryption systems to ensure 
data security at every point in die transmission chain. Fig. 7.3 illustrates nested encryption 
systems, where the service provider provides authorization, keys and the scrambled data to the end 
user through Encryption System A. During transit, System B is employed by die carrier to protect 
the data while in the communications networic. In fact, there arc two implementation choices even 
for this segment of the delivery system. The provider can use both a second layer of scrambling in 
conjunction with a different authorization and key distribution. (This system need not comply with 
the transmission ''Standards'* method.) Alternatively, System B could simply encrypt or scramble 
the encrypted keys distributed by System A, without die requirement of scrambling the actual 
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service data. The main appeal of this method is thai it is a low bandwidth/complexity solution, 
while its drawback is that it requires some knowledge of the System A key distribution method. 



OriginaJ 
Program 



Encryption 
System A 




Encryption 
System B 


interface 



Decoded 
Program 



to Common 
Carrier 



Communications 
Network 



Set-top 
(Decryption 
System A ) 




Decryption 
System B 









Figure 7.3. Nested encryption systetns. 

In Hg. 7.4, die two Encryption Systems are connected in series. System B is again used to protect 
the integrity of the data while in the communications network. System A is used by the local 
affiliate or cable company to authorize reception of the service within its own service area. 

In fact, the two topologies discussed above can be combined, where either System A or System B 
could be a Nested or Series configuration. The number of nesting/series combinations can be 
arbitrarily large. 
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Figure 7.4. Series encryption systems. 
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8. Local Program Insertion 

The Grand Alliance Transpon supports insertion of programs and commercials, by use of flags 
and fcamres dedicated to this purpose in the transport pactets Adaptation Header. The use of these 
syntax elements will need to be within some imposed constraints to ensure proper operation of the 
video decoders. Furthermore, there will be some constraints on some of current common 
practices, imposed not by the GA transport, but rather by vinue of the compressed digital data 
format 

The functionality of program insertion and switching of channels at a broadcast head-end are quite 
similar, the difference being in the time constants involved in the splicing process, and also in the 
fact that in the program insertion the bit stream is switched back to the old program after insertion 
is complete, while in the channel switching case one most likely switches over to yet another 
program at the end of the splice. There are other detailed issues related to the hardware 
implementation that may differ for these two cases, including input source devices and buffering 
requirements. For example, if program insertion is to take place on a bit stream obtained directiy 
from a network feed, and if the network feed does not include place-holders for program insertion, 
the input program transpon stream will need to be buffered up for the duration of the program 
insertion. If the program is obtained from a local device, e.g., a video server or a tape machine, it 
may be possible to pause the input process for the duration of the program insertion. Neither of 
these is an issue for channel switching. 

8.1. Systems level view 

There are two layers of processing functionality to address when doing program insertion. The 
lower layer functionaHty is related to spUcing of transport bit streams for the individual elements of 
the program, the higher level functionality is related to coordination of this process benveen the 
different elementary bit streams which make up the program transpon stream. Fig. 8.1 iUustiates 
die correa approach to implement program insertion. 
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Figure 8.1 Example Program Insertion Architecture 

The first step for program inseition to take place at a broadcast head-end is to extract (by 
demultiplexing) the packets, identified by the PIDs, of the individual elementary bit streams that 
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make up the program, including the bit stream carrying the program.map.iablc. Once these packets 
have been extraaed, as illustrated in Fig. 8.1. program insertion can take place on an individual 
PID basis. If applicable, some packets may be passed through wthout modification. There is also 
the flexibility to add and drop elementary bit streams. The splicing process for each PID is 
described in the next section. 

When program insertion takes place, the program^map.iable needs to be modified to reflect the 
properties of the program transport stream that is being spliced in. As described in the section on 
its syntax, the definition of the program.map.table allows the signaling of a change in the contents of 
a program transport stream ahead of time. The changes in the program definition could involve a 
change in the number of elementary bit streams that make up the program, either by addition or 
removal of bit streams, change in the PIDs used for the elementary bit streams, etc... 

The bit-rate of the program after splicing should have a known relationship to the bit-rate of the 
program before splicing, in most scenarios. Unless dynamic bit-rate allocation is possible for a 
program a: the system multiplexer (based on instantaneous bandwidth requirements), an increase in 
bit-rate after splicing can cause buffer overflow. A decrease in bit rate may be handled by 
transmitting null packets (packets with no information) or by allocating the extra bandwidth to 
other programs on a dynamic basis. These capabilities depend on the implementation of the system 
level multiplexing function, a function that is not a pan of the GA Transport specification. 

Bit rate constraints may also be imposed on individual elementary bit streams for the program that 
is insened, e.g., for compressed video, input and output bit rates need to be the same. In a perfect 
program insertion set up, the splice points for the different elementary screams in a program should 
be coordinated to correspond to the same instant in time in the overall program (which may not 
correspond to the same instant in time for each elementary bit stream) to permit seamless transition. 
Additional constraints on selecting the splicing points exist for particular applications such as video 
(Le., VBVJclay value). 

8.2. Basics of elementary bit stream insertion 

The interface for elementary bit stream insertion is at the cranspon layer of the protocol. This 
means that bit stream insertion always takes place in units of transport packets. The primary 
features enabling local elementary bit stream insertion are the dixontinuity.indicsor field and the 
splice.countdown fields in the transport header. The discondnuity.iiKiicaior signals ttecBecoder that the 
PGR is changing to a new time base. This simply informs the decoder that the rfEBiagc in the bit 
stream is not due to an error in the channel, but rather is intended by the program provider. The 
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implication for the dcccxier is that it should continue nonnal decoding, and it is the encoders 
responsibility to nuke sure that the bit stream has been constructed in a compliant manner (that is 
that decoders don't crash due to overflow or underflow.) 

The splice.counidown field in the adaptation header is used to signal a head-end or intermediate digital 
switch that a subsequent packet is the point for switching in a new bit stream. The count-down is a 
positive number which decrements on each subsequent packet of that service. The value of "0" is 
the last packet in the original sequence, and the value "-T* is resident in the packet which should 
initiate the switch over. The count will continue to decrement for channel error resilience. The 
behavior is shown in Figxirc 8.2. 



Splice countdown 

10-1-2... 



10-1-2, 



ill! 

Program 
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I I I I I I r 

Program confd 
t I I I I I t 



Transport 
Packet 



10-1-2 



•Local Commercial 



Figure 8.2. Local program insertion keyed on Splice countdown. 

The affiliate or headend equipment sets itself up for the switch based on the descending 
countdown. At the "-1" point, the local commercial is inserted while the network commercial 
continues. At the second trailing the affiliate returns to the network feed. This technique can 
be used for either local programs or local commercials. It does depend on the video encoder 
constraining its bit generation at the splice points so that the decoder buffer does not overflow. 

The GA transport encoder places some constraints on the encoding which are more stringent than 
the MPEG-2 requirements. The added constraint is that the PES header is followed immediately 
by a video access unit. This will speed acquisition. The first packet in an insertion will contain the 
PGR value, with the PGR discontinuity bit set to "1" to infonn the diecoder that a splice has 
occurred. The first payload in the stream will begin with a PES Header, which will have a PTS 
resident, so that the decoder can determine the display time immediately. Because the PES header 
also has the daia.alignment .indicator set, the first data following the header will be the start of the 
video sequence layer. Consequendy, the decoder has all the infonnarion available to begin 
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decoding immediately after receiving the beginning of the spliced commcrciaL (In general an 
MPEG-2 stream docs not have these constraints imposed, and hence does not have guaranteed 
pcrforaaance at the splice points.) 

8,3. Restrictions 

Compressed digital technology docs impose some restrictions on afBliate operations which naay 
differ from present practice. Although all present practices can be repUcaied by completely 
decoding and rccoding the video, there is a desire to implement as much as possible in the 
compressed video domain. The following comments are made with respect to processing xhc 
compressed video. 

Local commercials and network commercials will need to be stricdy controlled to be the same 
number of packets, and the same number of frames of video. This is contrary to the present 
practice where local inserts tnay differ from the planned network inserts by several seconds. 

A second restriction is tiiat affiliate pix-in-pix and affiliate text overlays can as^ be accomplished 
by decoding and recoding, 

8*4* Imperfect program insertion 

It may not always be possible for the program insertion process to meet the precise requirements of 
a seamless splice. This could be due to several reasons including the presence of infrequent splice 
points in the incoming bit stream or non-availability of the hardware required for precise splicing at 
die network affiliate. There are two scenarios for imperfect splicing. In die first scenario the 
network affiliate attempts to splice in the entire program as a whole, without attempting to align 
each of the component elementary bit streams. In this case, the exact splicing can take place for 
only one of the elementary streams. Since video is the most important component of the program, 
perfect alignment will be obtained for video. In this case the output of the odier elementary bit 
streams will not be presented at the output until synchronization of these bit streams is achieved 
As an example, audio should be muted until its elementary bit stream is synchronized 

In the second and most uncoordinated splicing approach, the splicing takes place without any 
attempt at coordination with the input bit strcanL In this case the video presentation process is 
affeaed around the splicing point. If the splicing takes place when the VBV level in the existing bit 
stream is less than it should be for perfect splice, there will be a period of time for which data is 
lost for the existing bit stream. In this case the decoder should freeze the bsft dispisycd frame. In 
the other case where VBV is fuller than expected, the decoder video data bufier may cvenmally 
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overflow during the time period of the spUced in bit stream. The decoder will then have to initiate a 
resynchronization procedure in the middle of the program, fieezing the display to Ae last decoded 
picture whUe this process is taking place. Note that when the process of splicing in a bit stream 
does not take place corrccUy, there wiU also be a disruption in service at the spUce back to the 
original bit stream. It is the recommendation of the G A that this type of spUcing be stricUy 
prohibited, since it leads to a very noticeable intcrmption of service. 

It is important to note that the process of facilitating frequent opportunities for spUcing in a 
program bit stream is not within tiie control of tiie transport layer of tiie system. The transpon only 
provides die mechanism of implementing the spUce itself. Hence decisions on determining the 
possible frequency of commercial insertion should also involve the people involved in the design 
of the source coding algorithms for applications like video and audio. 
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Transport System 

9. Compatibility with other Transport Systems 

The GA cranspon system is compatible with two of the most important alternative transpon 
systemSt namely the MPEG-2 transport stream definition, and also the ATM definition being 
finalized for Broadband ISDN. Furthermore, since several of the CATV (e.g., Digicipher II) and 
DBS systems being designed are considering use of the MPEG-2 Transport layer syntax, the 
degree of interoperability with such deployed systems should be quite high (possibly requiring a 
translation if the CATV or DBS system deploys a slighdy incompatible MPEG-2 variant). 

9.1. Interoperability with MPEG-2 

In the development of the GA oanspon specification, the intent has never been to limit the design 
by the scope of the MPEG-2 systems definition. The GA system is interoperable with MPEG-2 
decoders since the GA Transpon is currcntiy a constrained subset of the MPEG-2 Transpon 
syntax. The constraints are imposed for reasons of increased performance of channel acquisition, 
bandwidth efficiency and decoder complexity. If, in the course of future work, the MPEG-2 
standard is unable to efficiendy meet the requirements of the GA system, a deviation from MPEG 
would be in order. 

The ATV system requires definition of bit streams and services beyond the compressed video and 
audio services. A means of identifying such bit streams is necessary in the ATV system, but is 
not pan of the MPEG-2 definition. There is a method of encoding such a registration descriptor 
when a an authority to administrate registration is identified. This identification is implemented by 
the rcgistniiion_descriptor in the PSI stream. 

9.2. Interoperability with ATM 

The GA transpon packet size is selected to ease transferring these packets in a link layer that 
suppons Asynchronous Transfer Mode (ATM) transmission. There are several methods for 
mapping the Transpon packet into the ATM fomiat. Three techniques are presented, although the 
industry may converge to a different solution than those presented here. 

9.2.1. ATM Cell and Transport Packet Structures 

Figure 9. 1 shows the format of an ATM cell. The cell consists of two parts: a five byte header and 
a forty-eight byte information field. The header, primarily significant for ncwofffcing purposes, 
consists of the following fields: 

Grand Alliance HDTV System Specification Draft Document 

Page 58 

BNSOOaD: <XP 20551 75>V_L> 



GFC a four bit Generic Flow Control field used to control the flow of traffic across the 

User Network Interface (UNI). Exact mechanisms for flow control are under 
investigation. 

VPI an eight bit network Virtual Path Identifier. 

VCI a sixteen bit network Virtual Circuit Identifier. 

PT a three bit Payioad Type (i.e., user information type ID). 

CLP a one bit Cell Loss Priority flag (cUgibiUty of the cell for discard by the network 

under congested conditions). 
HEC an eight bit Header Error Control field for ATM header error correction 

AAL ATM Adaptation Layer bytes (user specific header). 

The ATM User Data Field consists of forty-eight bytes, where up to four of these bytes can be 
allocated to an Adaptation Layer. 

Figure 9.2 shows the format of tiie Grand Alliance transport packet A one hundred eighty-four 
byte packet data field (possibly including an optional and conditional adaptation field) is preceded 
by a four byte prefix. 

9.2.2. Null AAL Byte ATM Cell Formation 

The simplest method to form ATM cells from the Transport layer is the null AAL byte scrucmre 
shown in Figure 9.3. The Transport packet is partitioned into forty-eight byte payloads. applied 
direcdy to the information fields of die ATM celL The five byte ATM header is appended. Since 
the Transport packet length is not an integer multiple of the ATM ceU payioad, there will be only 
occasional aUgnment of the Transport header with the start of the ATM cell information field. 

9.2.3. Single AAL Byte ATM Cell Formation 

Alignment of the Transport packet and ATM cell is accommodated by paring the Transport packet 
into forty-seven byte segments, shown in Figure 9.4. Four such segments wiU exacdy encompass 
a Transport packet. A one byte AAL is appended, along with the five byte ATM header to fulfiU 
the fifty-three byte ATM cell requirement The AAL byte can cany useful infonnation concerning 
the transport data within the ATM cell. It can be viewed as an adaptation field for the contained 
data, conveying the original position of the ATM payioad within the Transport packet, for 
example, as weU as oUicr infonnation. For example, ATM standards prescndy provide for five 
different AALs, such as AAL Type I for accommodating connection oriented constant bit rate 
services, and AAL Type 2 for handUng connection oriented variable bit rate data services. 
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Dual AAL Byte ATM Cell Formation 
An alternative solution to cell/packet aUgnmcnt is shown in Figure 9 J. The transport header is 
discartied, and the remaining one hundred eighty-four byte payload is segmented into 46 byte 
incremenis. To these are added two AAL bytes and the five byte ATM header for each ATM 
p^^wt The idea here is that there may be a dupUcation in funcdonality in Ae ATM header and the 
link level transport header fields. A particular header field to consider for dupUcation of 
fiincrionaUty is the pm. If the PDD can be associated with a specific VPI and VQ used in the ATM 
headers of the packets carrying the data payload. and this FID mapping information can be sent to 
the destination terminal when the virmal path/ciicuit is set up (using the ATM signaling channel), it 
does not have to be transmitted for every GA packet The PID can then be reconstructed at the 
destination (using tiie information transmitted at call semp), and can then be appended to the one 
hundred eighty-four byte payload (reconstmcted from four ATM packets) to obtain the complete 
GA packets. Transport header information that cannot be reconstructed (e.g.. adaptation field 
control) should be carried as a pan of the two AAL bytes for each ATM cell, along with other 
additional information. Note that the above is only a suggested approach and does not represent a 
complete design. 
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